The present invention relates generally to computerized database systems and, more particularly, to a system and methods for improving distribution and execution of objects, including application objects, across multiple tiers of distributed computer environments.
Today, client/server systems abound. Such systems are characterized by a database server(s) connected to a multitude of clients, each client typically comprising a workstation or personal computer (PC) connected to a network. In a typical deployment of such a system, a client application, such as one created by an information service (IS) shop, resides on all of the client or end-user machines. Such client applications interact with host database engines (e.g., Sybase SQL Server.TM.), executing business logic which is mostly, if not completely, running at the client machines. Moreover, with present-day systems, it is possible for a client to take advantage of centralized business logic residing at the host database, typically written in the host database's proprietary or semi-proprietary language (e.g., Sybase T-SQL).
One approach to providing better distributed computing is to employ existing Distributed Computing Environment Remote Procedure Calls (DCE.backslash. RPCs). Using such an environment, one can store C programming code on a server, thus providing a centralized repository for business logic. Such an approach is problematic, however. At the outset, the difficulty of configuring such a Distributed Computing Environment is a daunting task, requiring highly skilled technicians (not only for installation but also maintenance). Further, most IS professionals charged with the task of creating database applications, although quite adept at developing client applications, have relatively little training or experience providing server-side logic. For instance, most of these individuals typically employ fourth-generation languages (4GL), such as Powersoft PowerScript.about., Paradox PAL.TM., Microsoft Visual Basic.TM., or the like. As a result, a minority of these individuals are adept at creating program logic in a lower-level language, such as C.
A particular problem exists with implementing a substantial amount of business logic on the client side. Over a period of time, a given database application can be expected to undergo various modifications, as that program undergoes further enhancements. Moreover, the business environment is a dynamic one. Accordingly, a program implementing business logic will expectedly undergo significant modifications over a period of time for adapting to ever-changing business logic. When the business logic requiring modification resides on the client side, the task of updating business logic includes the arduous task of updating each individual client machine. Given the difficulty of maintaining business logic at multiple clients (particularly in a large network environment), there is much interest in maintaining business logic in a centralized location.
Another difficulty in client/server environments is the disparity in capability from one client machine to another. Such environments are typically very heterogeneous, ranging from very powerful workstations on the one hand, to very limited or modest workstations on the other. Given such an environment, it is difficult, if not impossible, to deploy a large, complex application on all of these different client machines. In practice, one is limited by the lowest common denominator. Quite simply, the differences between the client machines make it extremely difficult to deploy a single application across such an environment.
One approach to addressing the foregoing problems is DCE or Distributed Computing Environment protocol--an emerging standard. To date, this "standard" has been difficult to implement and maintain (in addition to being a somewhat immature standard). In particular, the difficulty faced in implementing and maintaining the server side of such an environment remains an obstacle to widespread adoption. DCE is an RPC-based (i.e., Remote Procedure Call-based) solution where a portion of procedure calls are abstracted: an interface definition resides at the client with a corresponding interface definition residing at a receiver (i.e., remote computer, typically a server, which services the RPC calls). The task of coordinating a collection of servers in a DCE environment is an especially difficult one.
Another emerging standard is CORBA (Common Object Request Broker Agent), an object-based RPC-like standard. Like the DCE approach, CORBA provides a mechanism where two processes can communicate remotely, through a well-defined interface. Microsoft OLE (Object Linking and Embedding), a competing standard, also implements remote interprocess communication, through a well-defined interface. Although such standards have been proposed, with varying levels of maturity, to date there remains few tools available which would facilitate use of any one of these standards. Further, each standard incorporates proprietary technology, thus limiting the ability of these environments to interoperate with each other.
Implementing centralized business logic at a server is not itself without disadvantages, however. For departmental solutions, IS personnel desire to retain at least some control over a deployed application. With a centralized system, depending on how it is administered, clients may take offense to centralization of control if service is perceived as inadequate. The increasing popularity of "departmental computing" is, in large part, a response to the "glass house"--overly centralized computing. For departmental solutions, therefore, IS personnel want to retain at least some control. Although these individuals recognize the benefit of partitioning the business logic of an application, these individuals want to retain control--physical access--over machines which implement at least some of the business logic.
The cost of administering a centralized service greatly affects how well clients are serviced. As it is typically very expensive to employ skilled technicians for changing to business logic stored on a server (e.g., requiring expert C programmers), upper management is often unwilling to fund such changes. For departmental solutions, therefore, keeping the cost of modifications relatively low is an important consideration.
What is needed is a system with methods providing an n-tier development environment. Such a system would allow a programmer to create objects that contain business rules and which can be distributed onto one or more application servers, without any inherent limit as to how many servers can be employed. The present invention fulfills this and other needs.